This invention relates generally to communication systems, particularly to the control of communication systems using SONET/SDH standards. More particularly, the invention relates to communication between multiple communication services and a SONET/SDH communication system or network.
The Synchronous Optical Network (xe2x80x9cSONETxe2x80x9d) standard was originally developed as a multiplexing and trunking mechanism to carry a large number of voice channels over a single optical fiber. SONET and SDH are a set of coordinated ITU, ANSI and Bellcore standards that define a hierarchical set of transmission rates and transmission formats. Bellcore originally proposed the standard in the late 1980""s. Since then, the SONET standard has gained worldwide acceptance. Europe has adopted the SONET standard with a few minor modifications and is known as Synchronous Digital Hierarchy (xe2x80x9cSDHxe2x80x9d). Because of the standardization, interoperability between different vendor equipment has been achieved for the first time in WAN applications. In addition, because SONET/SDH transport is efficient, economical, robust and a reliable means to multiplex and transport a large number of voice channels over a single optical fiber, SONET/SDH deployment has progressed quickly and widely.
Although the original motivation for SONET/SDH specification was for transporting voice, the high bandwidth capability of SONET/SDH networks makes it attractive to transport multimedia traffic such as voice, video, and data efficiently on a single network. Recognizing this, SONET/SDH equipment vendors are now offering multimedia capability in their equipment. The solutions available today for incorporating multimedia services are inflexible and expensive because they require several single service devices to support multimedia services. Due to the enormous complexity of implementation, a single multiple service device has been unavailable that could support several protocols and formats of differing service types.
FIG. 1A illustrates the array of data bytes for a prior art SONET STS-1 frame 100. The STS-1 frame 100 consist of eight hundred and ten bytes and is always visually illustrated as array of 9 rows of 90 columns so that the Transport Overhead bytes (TOH) 101 line up properly at the beginning of the frame. As indicated in FIG. 1A, each byte in the STS-1 frame 100 can be associated with a column and row number of the frame. SONET overhead information is divided into section (SOH), line (LOH) and path (POH) overhead and is provided to manage the network and the transport of payload data 102. The section and line overhead make up the transport overhead (TOH) 101 of the STS-1 frame 100 and consist of 27 bytes in every STS-1 frame. The SONET payload data 102 is carried in a synchronous payload envelope (SPE), which makes up 9 rows by 87 columns of the STS-1 frame structure 100 or 783 bytes. Path overhead (POH) is contained within the SPE. The SPE can begin in any byte position within the STS-1 frame other than the first three TOH columns. Because there may be jitter and phase differences, the SPE does not need to be perfectly aligned within one SONET frame starting at the first row and fourth column in the STS-1 frame. The SPE may start at a different byte position and carry over into the next sequence of frames. The STS-1 frame is transmitted one row at a time, from top to bottom and from left to right within each row. Therefore, byte (1,1) in row 1, column 1 is sent first while byte (9, 90) in row 9, column 90 of a given frame is sent last. Other higher level SONET frames structures or hierarchies can be derived by knowing the frame structure for the STS-1 frame 100. For example the higher level SONET frame structure STS-3 has three times as many columns as the STS-1 and expands the SONET overhead information by three times. The overall frame structure of STS-3 is derived by simply interleaving a single byte at a time from each of the three equivalent STS-1s that make up an STS-3. The appearance is that every third column belongs to a given one of the equivalent STS-1 frames. The higher level SONET frame structure STS-48 is made up of 48 equivalent STS-1 frames such that every 48th column belongs to a given one of the STS-1 frames.
Referring to FIG. 1B, the generic higher level SONET frame structure STS-N 105 is made up of N equivalent STS-1 frame structures 100a-100n. The STS-N frame structure 105 has N times as many columns as the STS-1 100 and expands the SONET overhead information by N times as well as expanding the payload by N times. Every column represents a column from a given one of the N equivalent STS-1 frames 100a-100n that is interleaved into a column of a given one the STS-N frame 105. For example, the first column of the first equivalent STS-1 frame 100a is interleaved into the first column of the STS-N frame 105. The first column of the second equivalent STS-1 frame 100b is interleaved into the second column of the STS-N frame 105. The first column of the third equivalent STS-1 frame 100c is interleaved into the third column of the STS-N frame 105. The first column of the Nth equivalent STS-1 frame 100n is interleaved into the Nth column of the STS-N frame 105. Similarly, the last column of the Nth equivalent STS-1 frame 100n is interleaved into the last column of the STS-N frame 105. As a result, the transport overhead (TOH) 106 of the STS-N 105 frame structure has N times more bytes than the STS-1 frame 100 and the SONET payload data 107 which carries the SPE 107 has N times more bytes than the SPE 102 of the STS-1 frame 100. Note that the generic STS-N frame structure 105 reduces to standard frame structures when N is defined. For example, the STS-N frame structure 105 reduces to an STS-1 frame when N is 1. Similarly, the STS-N frame structure 105 reduces to an STS-48 frame structure when N is 48. As indicated in FIG. 1B, each byte in the STS-N frame 105 can be associated with a row number, column number, and a subcolumn number. The subcolumn number indicates the association of the equivalent STS-1 frames within the higher level STS-N frame structures. For example byte (1,1,1) of STS-N frame 105 having a row number 1, a column number 1, and a subcolumn number 1 is associated with byte (1,1) of the first equivalent STS-1 frame 100a. Byte (9,1,3) of STS-N Frame 105 having a row number 9, a column number 1, and a subcolumn number 3 is associated with byte (9,1) of the third equivalent STS-1 frame 100c. Byte (9,3,N) of STS-N frame 105 having a row number 9, a column number 3, and a subcolumn number N is associated with byte (9,3) of the Nth equivalent STS-1 frame 100n. Byte (9,90,N) of STS-N frame 105 having a row number 9, a column number 90, and a subcolumn number N is associated with byte (9,90) of the Nth equivalent STS-1 frame 100n. 
Unchannelized or nonchannelized carriers are available in the SONET frame structure and are known as concatenated SONET frames. Concatenated SONET frames are referred to as STS-Nc which has N concatenated SONET payload frames. N is presently defined by the SONET specifications for concatenated SONET payloads to be greater than 2.
The SONET payload for an STS-1 can be broken into smaller portions or payloads. The SPE of each STS-1 can be broken into seven virtual tributary groups (VTGs) each consisting of one hundred and eight bytes which occupies 12 columns of an SPE. Within each VTG there may be subrate virtual tributary (VT) types.
Currently defined subrate VT types include VT1.5, VT2, VT3, and VT6. VT1.5 is twenty-seven bytes or three nine byte columns and a single VTG can carry four VT1.5s. VT2 is thirty-six bytes or four nine byte columns and a single VTG can carry three VT2s. VT3 is fifty-four bytes or six nine byte columns and a single VTG can carry two VT3s. VT6 is one hundred eight bytes or twelve nine byte columns and a single VTG can carry one VT6. Similar to how the SPE can begin at different columns within a SONET frame, the payload for subrate VT types can float therein.
FIG. 1C illustrates a prior art implementation of providing communication between multiple services and a SONET/SDH communication system . The prior art system contains multiple inflexible devices each providing dedicated support for a single service type before being multiplexed onto the SONET/SDH stream. For example, Service#1 151, Service#2 152, and Service#3 153 may respectively be voice data, video data and generic data which may comprise multiple services. In this case, SONET Bandwidth 150, the network bandwidth in number of bits per second for transmission of a SONET frame, are allocated to the SONET overhead 160, Service#1 168, Service#2 169, and Service#3 170. Each of these services 151-153 require dedicated mappers 154-156 that can receive a certain type of communication service in its native data format, convert it into a specific type of non-native data format such as ATM cells or Packet data, and then map the service data in its nonnative data format into an SPE of a fixed SONET frame. The mappers 154-156 each represent a different circuit and are dedicated to the type of data and thus work with only a single service type. The mappers 154-156 first transform the native data format of the service type into a non-native format that is standard with every mapper. For example, consider that mapper 154 receives TDM data, mapper 155 receives Packet data, and mapper 156 receives Frame Relay data. Before mappers 154-156 map any data into a SONET payload, they would convert the native data formats of TDM, Packets, and Frame Relay into ATM cells for example. Additionally, the mappers define a fixed number of service types and service streams that may only be changed by first removing the original hardware and replacing it with the desired new hardware. When receiving a SONET stream for communication to the multiple services, the dedicated demappers 171-173 are required that can demap the SONET frame and convert service data in a non-native data format back into its native data format for each of the services 151-153. In order to demap the SONET SPE into service data, each of the demappers 171-173 must know how to convert non-native service data format into the native service data format. Similar to the mappers 154-156, the demappers 171-173 each represent a different circuit and are dedicated to the type of service data it can handle and thus work with only a single service type.
A disadvantage of the prior art is that the bandwidth, the number of bits per second for transmission of a SONET frame, for each service is fixed by the bandwidth of the mapper and the de-mapper required for supporting the non-native format of the service data. Another disadvantage of the prior art is that it uses SONET/SDH bandwidth inefficiently particularly when a service type does not need the entire bandwidth associated with a mapper and a de-mapper. Another disadvantage of the prior art is that a given service type may not get sufficient bandwidth because of bandwidth limitations of the prior art mappers and demappers. A further disadvantage of the prior art is that the hardware employed in prior art SONET/SDH communication systems is inflexible and requires the removal of dedicated mapper and demapper circuits and insertion of new dedicated mapper and demapper circuits in order to make a change in the communication system.
The present invention is a SONET/SDH universal framer (SURF) that interfaces at one communication port using SONET/SDH frames and interfaces with other communication services at other ports using the native data format of the service. In order to support the multiple communication ports a provisioning register is used to flexibly store provisioning information that describes the communication system and communication ports by describing the type of SONET/SDH frames expected, the types of services supported and the number of data streams of each service type. To process the multitude of SONET/SDH data formats and the Service data formats, byte engines are introduced whereby information is processed a byte at a time and intermediate processing states are restored, processed, and saved when it is necessary to preserve the state such as when changing to process a different data stream or a different frame of data. The SONET/SDH byte engine processes complex hierarchical SONET/SDH frames using the provisioning information describing the communication system and knowing the construction of the complex hierarchical SONET/SDH frames. Generally, intermediate states of the SONET/SDH byte engine are restored, processed, and saved when changing to process a different SONET/SDH frame of data. A service byte engine, comprising a plurality of simpler byte engines, is provided to process the multitude of Service data formats. Generally, when the service byte engine changes to process a different stream of the same Service data format, the intermediate states of that service byte engine are restored, processed, and saved, otherwise, the intermediate states are restored, processed, and saved when a different frame of data is processed. An elastic storage means, a memory, is used to allow the SONET/SDH byte engine and the Service byte engine to operate independent of one another in an asynchronous mode. The SONET/SDH byte engine stores information into the elastic storage means so that the Service byte engine can start processing it for transmission to the services. The Service byte engine stores information received from the services into the elastic storage means so that the SONET/SDH byte engine can start processing it for transmission out to the SONET/SDH supported communication system.
It is an object of the present invention to provide a single flexible device for the support of multiple services for SONET/SDH communication systems.
Another object of the present invention is to provide a flexible method of mapping multimedia services into SONET/SDH streams.
A still further object of the present invention is to eliminate the need for inflexible fixed bandwidth mappers and demappers of SONET/SDH communication systems thereby lowering the costs of such communication systems.
A still further object of the present invention is to provide a provisioning mechanism that allows for the bandwidth to be varied dynamically for each desired service and thereby altered by software means.
A still further object of the present invention is to provide a unified piece of hardware for processing SONET/SDH frames a byte at a time.